Recovering from a Disaster in an Exchange Server 2010 Environment: Identifying the Extent of the Problem (part 2)

Data Is Okay, Server Just Doesn’t Come Up

The failure of a server does not necessarily mean that the data needs to be restored completely from tape. Often, a server goes down because of a failure with the power supplies, a motherboard failure, or even a processor failure. In a situation where the hard drives on a dead server are still operational, the hard drives should be moved to an operational server or, at the very least, the data should be transferred to a different server. By preserving the data on the drives, an organization can minimize the need to perform more complicated data reconstruction from a tape restore, which could result in the loss of data from the time of the last backup. Restoring from tape should always be considered a final option.

This type of a failure is an excellent example of where you can take advantage of a Database Availability Group architecture. When utilizing a DAG, the failure of a mailbox server doesn’t actually prevent the users from accessing their email. When the master copy of the mailbox replica fails, the second priority copy becomes the master copy, and replication to any additional replicas continues. In this scenario, there would be no need to restore the failed server. Rather, you would simply build a new server from scratch at their convenience and add it back to the replica list. When replicated, you can choose to make this copy the master copy again. Similarly, if the failed system were a client access server or a Hub Transport server, if there were more than one server in that role in the site, the overall Exchange Server 2010 services would still be available when a single system failed. Rather than being restored, this system could be rebuilt and would take up its share of the load.

Data Is Corrupt—Some Mailboxes Are Accessible, Some Are Not

Data corruption typically occurs on Exchange servers when the time period since the last database maintenance is too long or maintenance has been neglected altogether. Without periodic maintenance, the databases in Exchange Server are more susceptible to becoming corrupt. Exchange Server database corruption that is not repaired can make individual messages or entire portions of mailboxes stored on an Exchange server to become inaccessible.

When a mailbox or multiple mailboxes are corrupt, the good data in the mailboxes can be extracted with minimal data loss. By isolating the corruption and extracting good data, an organization that might not need to recover the lost data can typically continue to operate with minimal downtime.

Data Is Corrupt, No Mailboxes Are Accessible

Depending on the condition of an Exchange Server database, the information might be so corrupt that none of the mailboxes are accessible. Recovering data from a corrupt database that cannot be accessed is a two-step process. The first step is to conduct maintenance to attempt to repair the database; the second step is to extract as much information from the database as possible.

In the case of a DAG configuration, if the database became unavailable due to localized corruption, you could simply make a different replica of the master copy and services would be restored.

Exchange Server Is Okay, Something Else Is Preventing Exchange from Working

If you know that the Exchange server and databases are operational and something else is preventing Exchange Server from working, the process of recovery focuses on looking at things such as Active Directory, Internet Information Services (IIS), the domain name system (DNS), and the network infrastructure, as with site-to-site connectivity for replication.

Mail Is Not Flowing Between Sites

If users can access their mailboxes normally and mail can be sent between users of the same site, odds are the issue is with the Hub Transport server. In larger implementations of Exchange Server 2010, the Hub Transport server role is likely to be run on a system that doesn’t host mailboxes. Generally speaking, backups are not performed on a Hub Transport server as it contains no unique information. To restore these services, simply rebuild the Hub Transport server. Installing with a /recoverserver switch enables the server to recover its configuration from Active Directory, saving some configuration steps. This assumes the server is built with the same name.

If you need the transport services up rapidly, consider adding the Hub Transport server role to an existing system. To add this role, follow these steps:

Internet Mail Is Not Flowing

If you cannot send mail to the Internet or receive mail from the Internet, there is a good chance that the issue is a failure with the Edge Transport server. Most environments should run more than one Edge Transport server, preferably in different locations. But if an Edge Transport server fails, it should be rebuilt as they are typically not backed up. Installing with a /recoverserver switch enables the server to recover its configuration from Active Directory, saving some configuration steps. This assumes the server is built with the same name.

If you need the transport services up rapidly, consider adding the Edge Transport server role to an existing system. To add this role, follow these steps: